Exposure and Risk
You must understand that
security is really “risk management” or “risk mitigation.” It can be
very difficult to completely secure an application or environment.
However, you are able to control or limit damage by following certain
practices. Your data and applications have different levels of security
requirements depending on the exposure endpoints (an exposure endpoint is defined by who is using the application and data). Figure 1
shows a simple matrix of data and application sensitivity versus the
exposure endpoints of that application. By definition, the more external
facing your application is (such as to the Internet) and the higher the
sensitivity of the data involved, the higher risk precautions you have
to take.
Let’s say you have an
internal company SQL Server–based application that has only very low
sensitivity data (public-facing data such as benefits data). You freely
share this type of data with whoever wants to see it. The types of
controls or rigor are likely very small for this type of
application—perhaps as simple as an integrated Active Directory with
your SQL Server and read-only access for all user roles.
On the other side of
the spectrum, you may have applications generating financial
transactions with credit card data that must have zero vulnerabilities,
encrypt data across the network, encrypt data at rest within SQL Server,
and use the new SQL auditing feature for database-level monitoring of
all data accesses.
A
big part of the risk management aspect is understanding what the impact
of this risk would be if your system is compromised. It is always best
to identify this aspect up front in some type of risk “cost” or
“impact.” Many financially strong companies have gone out of business as
a result of security breaches they had not anticipated or considered.
It is better to plan for such risk from the beginning.
Another aspect to consider
is staying compliant with data you use in nonproduction environments.
Often, companies needlessly put their entire livelihood at risk by using
live data values in nonproduction environments. If PII or other
company-sensitive data is available in your nonproduction environments
(such as in Development, Test, and Quality Assurance platforms), you are
violating laws and regulations around the globe and putting your
company and your customers at risk. You can easily employ data
subsetting and masking to your nonproduction data. Putting this practice
in place is a great idea.
Across the Life Cycle
A part of good design is how you have
complied with laws and regulations, how you have protected the data you
access or store, how you have secured your application and data, and how
you have verified all this. For these reasons, we provide some details
and describe what must be done across the development life cycle to
properly address security and compliance. We term this process the “risk
mitigation” of what you build.
Figure 2
shows a formal waterfall development life cycle with key security and
compliance items identified at each relevant phase. Getting into the
risk mitigation business starts by giving security and compliance the
full commitment and recognition they deserve.
This step starts with a clear
statement of security and compliance objectives as you are sizing up
your application in the assessment phase. These objectives often take
the form of stating how you will address the rules, laws, data
sensitivities, access considerations, and eventual end users (and the
countries they reside in).
Next, you focus on the clear
identification and specification of all security and scope of
compliance. You look at the details of exactly where the compliance or
security lines need to be, determine how you must fully address them,
and clearly identify which must be adhered to for your application.
Often, organizations have security information analysts and data privacy
groups that contribute to this part of your development efforts. They,
in turn, bring others to the table, such as legal, auditing, and even
corporate communications folks.
As you go into the design
phase, you must complete the full analysis and design of every security
and compliance element for your application. As part of this analysis
and design phase, you should start enumeration test plans that must be
completely verified before your application can be delivered to its
users.
In
the prototyping phase, you have a chance to start demonstrating how
security, access, privacy, and compliance will be addressed. This phase
is very important because of all the complications, rules, laws, and
issues that are at stake and must be verified. We have not run a
development effort without extensive prototyping of as many security and
compliance tests as are humanly possible. It is this risk that must be
fully addressed early and never as an afterthought!
As you fully code and test
your database and application, you must never skip the security testing
and validation. It is best to put these tests first
in your overall test plans. As your application completely takes shape,
a complete application scan for vulnerabilities can be performed.
Popular tools such as AppScan are essential tools of the trade for
performing this task.
Finally, as you near deployment,
you should make sure all the security and compliance acceptance tests
are met. You need to capture these results fully because the successful
completion of this part of acceptance testing can be shown in SOX
compliance auditing.
The Security Big Picture
Now, let’s turn to the bigger
security and compliance picture that shows many of the layers involved
in a broader security enforcement approach. Figure 3
shows many of these layers, starting at the top with solid guidelines,
policies, and compliance-reporting capabilities. You must start with
these components to guarantee that you are aware of what must be done
and have a way to show you are doing what the policies outline.
Next, you must define and
create other aspects of security and compliance, such as security event
management, alerting and monitoring, complete threat models, and
vulnerability assessment objectives. These types of components must also
reach into and be enforceable across major events such as disaster
recovery (to ensure business continuity) and continue to support what
you have deployed around identity management and single sign-on.
The next inner layer is where
your database security is defined, along with any database-level or
database instance–level auditing you put into place. It is also this
layer where messy things such as SQL injection can occur and Denial of
Service often surfaces. Getting some type of intrusion detection and
prevention scheme into place is essential.
Moving further down the layers
of security, you find file integrity checking, secure Internet
protocols, disk-level encryption, and other security-enhancing items.
They all work together to bring you what should be a more secure (and
compliant) place to deploy your applications within.
With SQL Server 2008 R2, you are essentially out-of-the-box ready to do absolutely nothing.
In other words, Microsoft has taken the policy to “allow nothing,” and
any access, execution, or other action must be explicitly granted.
Believe it or not, this is the right thing to do. This approach ensures
that all objects and accesses are explicitly declared and, by
definition, are fulfilling security and many compliance regulations. The Open Web Application Security Project (OWASP; www.owasp.org) lists its recent top 10 application vulnerabilities as follows:
SQL Injection
Cross-Site Scripting
Broken Authentication and Session Management
Insecure Direct Object References
Cross-Site Request Forgery
Security Misconfiguration
Failure to Restrict URLs
Unvalidated Redirects and Forwards
Insecure Cryptographic Storage
Insufficient Transport Layer Protection
Identity Access Management Components
One of the key areas identified in the security big picture (as you can see looking back at Figure 3)
is identity management. It is key in the sense that well-managed
identities are essential to well-managed security. There is a quite a
bit to consider when talking about identities. Figure 4
shows a common “identity universe” for a company that has both
internal- and external-facing applications. In other words, identities
are both customers that interact with the business and internal
identities such as employees and other workforce identities
(contractors, temps, partners, and so on). Both sets of identities must
be managed well, and often there are overlapping identities that require
accesses (and identity management) in both areas (internal and
external).
Often, companies use one
internal-facing LDAP directory such as Microsoft’s Active Directory for
managing their internal identities and then another LDAP directory such
as Sun One LDAP for managing all external-facing identities (for
forums, eStore, and so on). Then they create triggers or synchronization
jobs that do a “search before create” type of processing when new
identities are created within either LDAP directory. Because overlap is
rare, not much extra “create” overhead occurs, but when they do overlap,
only one identity (such as a partner identity that might be in that
company’s internal and external LDAP directories) gets created. This is
effectively “mastering” the user identities. It is recommended that you
consider both sources of identities at all times. You should also
establish strict access roles for all identities with the least rights
going to anonymous identities.
More and more companies are
also now moving to concepts such as Open ID, where a company can utilize
the authentication and identification established by third-party Open
ID providers and grant trust to these identities with very high
confidence. The industry is moving this way fast. Figure 13.5 shows the logical components of identity access management.
This
figure shows that you must carefully address full identity life-cycle
management, which includes user ID management, credential management,
entitlement management, identity integration (between multiple LDAPs),
and provisioning and
deprovisioning identities. Access management is all about
authentication, single sign-on, authorization, and impersonation and
delegation rules. And, the directory services themselves define the
users, groups, all attributes (or elements) of a user or group, roles,
policies to enforce, and credentials to be used. All applications and
access points must be plugged in to this identity access management
framework. All risk is minimized by a sound identity access management
foundation.
Compliance and SQL Server
On the global level, hundreds of
compliance laws are in place that affect almost every aspect of data
access, data protection, data movement, and even data storage. Countries
such as Germany now have some of the most severe data compliance rules
on the planet, such as strict control of how certain personal data is
stored and what personal data can be stored; these rules even prohibit
personal data from being transmitted (or moved) across German borders.
If you are planning to create applications and databases that will span
countries or contain sensitive or private data, you must “design in” the
rules and enforcements from the beginning.
Let’s address the most common
“sensitive” data: Personal Identifiable Information (or PII for short).
PII data is at the center of most global data privacy laws and
regulations. As you can see from a subset of the PII data model in Figure 6,
PII data is any personal information that identifies an individual,
such as name; address; driver’s license number; other government-issued
identification (such as passport number); and even gender, ethnicity,
and age.
If you have any databases
or applications that have this type of data in it, you are bound by
local and/or regional laws and regulations whether you like it or not.
It is the law. You must then protect this data in accordance with those
regulations and laws; otherwise, you become liable for fines, lawsuits,
or worse (risk exposure of that data could put you out of business). As
you can also see in Figure 13.6,
there are different sensitivity levels around PII data. Something like a
person’s name is considered low sensitivity, whereas an employee ID is
considered medium sensitivity. And marital status, gender, Social
Security number, bank account number, driver’s license number, and
passport number are considered high sensitivity and often must be
treated with special care and feeding with capabilities such as
encryption in transit and at rest (while stored in a table).
Following is a list of some
of the many laws and regulations that have been put into effect and that
you will likely have to address in your application:
The Health Insurance
Portability and Accountability Act (also known as HIPAA) was introduced
in 1996 to protect critical health and patient information. HIPAA forces
companies to strictly control data identified under its jurisdiction.
The
Sarbanes-Oxley Act (known as SOX), put into place in 2002, requires
auditors to assess and report on the effectiveness of a company’s
internal controls on information and extend into the authorization of
access and updates to data.
The
Gramm-Leach-Bliley Act (GLBA) of 1999 further defines steps that must
be taken by financial institutions to protect, secure, and prevent
access of core financial data.
California’s
Information Practices Act of 2005 details strict controls around PII
data, what needs to be encrypted, and laws surrounding breaches of
controlled data.
The
Children’s Online Privacy Protection Act, passed in 1998, focuses on
the procedures to protect the confidentiality, security, and integrity
of personal information collected from children.
Other
industry-oriented laws and regulations have emerged, such as the Payment
Card Industry data security standard (PCI standard). It is focused on
what must be done to ensure credit card information is secure from the
moment a customer makes a purchase until the merchant disposes of the
credit card transactions.
